<?xml version="1.0"?>
<doc>
    <assembly>
        <name>CompoundFile</name>
    </assembly>
    <members>
        <member name="T:dotnetpcf.CompoundFile.DirTable">
            <summary>
            Directories work exactly like their file system counterparts. However they can have file names
            of any length and contain any characters.
            </summary>
            <remarks>
            
            </remarks>
        </member>
        <member name="P:dotnetpcf.CompoundFile.DirTable.EntryCount">
            <summary>
            Number of file table entrys
            </summary>
        </member>
        <member name="T:dotnetpcf.CompoundFile.FSFilterStream">
            <summary>
            Makes a file, which can span many non-sequential blocks, appear as a single contigious stream of data.
            </summary>
            <remarks>
            The FSFilter stream has a in memory cache that is big enough to hold exactly one file block. All reads
            or writes are read to/from the cache. The cache is flushed to the physical stream when moving from one
            block to the next or when the file is closed. It is very important that the user remembers to call 
            .Close() on this stream, if the dont the cache will not be saved. Unlike other classes derived from the
            stream class, calling .Close() will not close the physical stream as the physical stream has many filter 
            streams
            </remarks>
        </member>
        <member name="T:dotnetpcf.CompoundFile.CompoundFile">
            <summary>
            User level class that provides additional user friendly functionality. This is that class 
            that all users ofthe compound file should be creating. See CompoundFileSys for more 
            system level information.
            
            This class adds another layer over the system level functionality. For instance it exposes the 
            CFDirector and CFDirectories classes which make navigating and working with the directories 
            very user friendly. The user of this class should have no access to the underlying classes and
            should not need to know about them to be able to use this class.
            </summary>
        </member>
        <member name="T:dotnetpcf.CompoundFile.CompoundFileSys">
            <summary>
            The system level class that provides the basic compound file functionality.
            This class is intended for internal use only.
            </summary>
            <remarks>
            Design goals
               1) Hierachial file structure in single file (compound file)
               2) Demand loading of streams. i.e. Do not need to load entire file just to read a single stream
               3) Usable from non-dotnet languages, the main consequense of this being that no serialization was used
               4) The compound file implementation should not add a big space/speed overhead
            
            The physical file is split into blocks of SysInfo.BLOCK_BYTE_SIZE (currently 2048) bytes each.
            
            block 0 - Always the compound file header (CompoundFileHeader) which contains vital
            system information, including the block indexes of the other system blocks. 
            
            For this version the 4 system blocks have fixed starting positions. This may change in future
            versions and there positions must be read from the header. The other system blocks are listed
            below along with a short description, see the classes that implement these blocks for more information
            
            block 1 - The allocation table. Each block in the file is described by a single entry in the alloc table
            block 2 - The file table. Files can span multiple blocks, files belong to dirs
            block 3 - The dir table. Dirs are hierachial.
            block 4 - The names table. All file/dir names are stored in the names table which is saved to a single file
            
            
            Order of loading the compound file
               1) The compound file header is loaded
               2) The allocation table is loaded
               3) The file table is loaded. Once the file table is loaded FSFilterStreams can use used to load
                   all other data
               4) The dir table is loaded
               5) The names table is loaded
            
            </remarks>
        </member>
        <member name="M:dotnetpcf.CompoundFile.CompoundFileSys.InitNewFile">
            <summary>
            Initialises a new stream as a compound file
            </summary>
        </member>
        <member name="M:dotnetpcf.CompoundFile.CompoundFileSys.FillUnusedBlocks">
            <summary>
            Fills all unused blocks with a '*' character
            </summary>
        </member>
        <member name="M:dotnetpcf.CompoundFile.CompoundFile.OpenFile(System.String)">
            <summary>
            Open an existing compound file
            </summary>
            <param name="sFileName">Path and file name</param>
        </member>
        <member name="M:dotnetpcf.CompoundFile.CompoundFile.OpenFile(System.IO.Stream)">
            <summary>
            Open an existing compound file
            </summary>
            <param name="sFileName">Path and file name</param>
        </member>
        <member name="M:dotnetpcf.CompoundFile.CompoundFile.MoveToRootDirectory">
            <summary>
            Set the root as the working directory
            </summary>
        </member>
        <member name="P:dotnetpcf.CompoundFile.CompoundFile.WorkingDirectory">
            <summary>
            Return the current working directory
            </summary>
        </member>
        <member name="T:dotnetpcf.CompoundFile.CFFile">
            <summary>
            User level class that provides access to a file 
            </summary>
        </member>
        <member name="T:dotnetpcf.CompoundFile.CFDirectory">
            <summary>
            User level class that provides access to a directory
            </summary>
        </member>
        <member name="M:dotnetpcf.CompoundFile.CFDirectory.#ctor(dotnetpcf.CompoundFile.CompoundFile,dotnetpcf.CompoundFile.DirTable.DirTableEntry)">
            <summary>
            
            </summary>
            <param name="cf">compound file</param>
            <param name="dent">this dir entry or null for root</param>
        </member>
        <member name="T:dotnetpcf.CompoundFile.CFNames">
            <summary>
            CFNames stores a list of all the "names" used by the compound file. These are strings such as the names of
            directories and files. Each of these items stored an ID of its name, rather than the string itself.
            </summary>
        </member>
        <member name="T:dotnetpcf.CompoundFile.SysInfo">
            <summary>
            Class containing system wide consts
            </summary>
        </member>
        <member name="T:dotnetpcf.CompoundFile.CompoundFileResult">
            <summary>
            Possible return values
            </summary>
        </member>
        <member name="T:dotnetpcf.CompoundFile.CompoundFileException">
            <summary>
            Custom exception class, has a CompoundFileResult member
            </summary>
        </member>
        <member name="T:dotnetpcf.CompoundFile.BlockHeader">
            <summary>
            Header block used by the tables (dir, file and alloc)
            Loaded/saved before the table specific headers
            </summary>
        </member>
        <member name="T:dotnetpcf.CompoundFile.CompoundFileHeader">
            <summary>
            The compound file header
            </summary>
        </member>
        <member name="T:dotnetpcf.CompoundFile.NotifyHashtable">
            <summary>
            Overriden hashtable class that calls a callback when it is modified
            </summary>
        </member>
        <member name="T:dotnetpcf.CompoundFile.AllocTable">
            <summary>
            Each block in the file is described by a single entry in the alloc table
            </summary>
            <remarks>
            There can be more than one allocation table block in a compound file. Since the allocation
            table is loaded before the file table, the FSFilterStream can not be used to load the alloc
            table entries. For this reasone the AllocTableHeader has a m_iNext member which contains the
            block index to the next allocation table block. 
            
            Allocation table entries can be chained to create large virtual blocks of data (e.g. files)
            Each allocation table entry has a m_iNext member which is used to chain entries
            </remarks>
        </member>
        <member name="M:dotnetpcf.CompoundFile.AllocTable.LoadFromStream(System.IO.Stream)">
            <summary>
            Loads the allocation table from a stream
            </summary>
            <param name="strm"> </param>
        </member>
        <member name="M:dotnetpcf.CompoundFile.AllocTable.SaveToStream(System.IO.Stream)">
            <summary>
            Saves the allocation table to the file. This is a rather complex routine
            as it needs to allocate new while saving the table. Other classes will use
            a FSFilterStream to hide this complexity, but this is not possible with
            the Allocation table. 
            
            The reson is that the allocation table must be loaded before a FSFilterStream
            can be used. This is because a FSFilterStream used the allocation table to move
            from one block to the next. 
            
            This method saves the allocation table and stores a "next pointer" in each
            alloc table block that is allocated. When the alloc table is loaded the load
            method can follow these "pointers" and load the entire table
            
            NB note that while saving the stream more alloc entries can be created, 
            these entries are stored in a temp list and stored last
            </summary>
            <param name="strm">A physical stream, not a FSFilterStream!</param>
        </member>
        <member name="M:dotnetpcf.CompoundFile.AllocTable.SaveEntries(System.Int64@,System.Collections.IDictionaryEnumerator,System.Collections.Hashtable@,dotnetpcf.CompoundFile.AllocTable.AllocTableHeader@,System.IO.Stream)">
            <summary>
            Helper for SaveToStream. Any new allocation table blocks that are created while saving the 
            allocation table are stored in the NewEntries list. These items must then be passed in the
            EntriesToSaveEnum to this method. This must happen untill no more items have been added to
            NewEntries
            </summary>
            <param name="iLastBlockStartPos"> </param>
            <param name="EntriesToSaveEnum">Current entries to save</param>
            <param name="NewEntries">List in which new entries will be saved</param>
            <param name="currentHeader">Current alloc table header</param>
            <param name="strm">Stream to save to</param>
        </member>
        <member name="M:dotnetpcf.CompoundFile.AllocTable.GetNewAllocTableEntry(dotnetpcf.CompoundFile.AllocTableFlags)">
            <summary>
            Create a new allocation table entry and creates space in the physical stream if requried
            </summary>
            <param name="flags">The flags for the new allocation entry</param>
        </member>
        <member name="M:dotnetpcf.CompoundFile.AllocTable.GetNewFileBlocks(dotnetpcf.CompoundFile.FileTable.FileTableEntry,System.UInt32)">
            <summary>
            Add another block to an existing file. This is an allocation table task, which is why
            this function is not in the FileTable class.
            Returns the ID of the new allocation block added to the file 
            </summary>
            <param name="fent">The exsisting file's file table entry</param>
            <param name="iNumBlocks">Number of blocks required</param>
        </member>
        <member name="T:dotnetpcf.CompoundFile.AllocTable.AllocTableEntry">
            <summary>
            Single allocation table entry
            </summary>
        </member>
        <member name="T:dotnetpcf.CompoundFile.FileTable">
            <summary>
            </summary>
            <remarks>
            Files are can span multiple allocation table entries and are used to create large streams of data.
            See FSFilterStream which makes a File appear to be a single sequential stream of data.
            
            Files also belong to directories, this is what creates the hierachial structure required by the
            compound file. However files are not physically related to the directories to which they belong.
            A file is related to its directory by the m_iDirID member in the FileTableEntry. Thus to "move"
            a file from one directory to another simply means changing this value.
            </remarks>
        </member>
        <member name="M:dotnetpcf.CompoundFile.FileTable.FindAllocTableEntry">
            <summary>
            Returns the entry for the file table or null if it was not found
            </summary>
        </member>
        <member name="M:dotnetpcf.CompoundFile.FileTable.BuildAllocBlockList(System.Collections.ArrayList@,dotnetpcf.CompoundFile.FileTable.FileTableEntry)">
            <summary>
            Builds a list of alloc tbl IDs that this file spans
            </summary>
            <param name="List">List to populate</param>
            <param name="fent">FileTableEntry for file</param>
        </member>
        <member name="M:dotnetpcf.CompoundFile.FileTable.GetNthBlock(dotnetpcf.CompoundFile.FileTable.FileTableEntry,System.UInt32)">
            <summary>
            Get the alloc block at iIndex
            </summary>
            <param name="fent">The file entry</param>
            <param name="iIndex">The zero based index</param>
        </member>
        <member name="M:dotnetpcf.CompoundFile.FileTable.EnsureFileHasNBlocks(dotnetpcf.CompoundFile.FileTable.FileTableEntry,System.UInt32)">
            <summary>
            Alloc new blocks if nessasary so that the file will have iNumBlocks
            </summary>
            <param name="fent"> </param>
            <param name="iNumBlocks"> </param>
        </member>
        <member name="M:dotnetpcf.CompoundFile.FileTable.CreateNewFile(dotnetpcf.CompoundFile.AllocTableFlags,dotnetpcf.CompoundFile.FileFlags,System.String)">
            <summary>
            Create a new file table entry and the associated allocation table entries
            </summary>
            <param name="allocFlags">Allocation table flags for the new block</param>
            <param name="fileFlags">File table flags for the new file</param>
            <param name="sFileName">Name of the file (can be null or empty)</param>
        </member>
        <member name="M:dotnetpcf.CompoundFile.FileTable.GetFileTableEntryByID(System.UInt32)">
            <summary>
            Find a file table entry by its ID
            </summary>
            <param name="iID"> </param>
        </member>
        <member name="M:dotnetpcf.CompoundFile.FileTable.AddNewFileTableEntry(System.UInt32,dotnetpcf.CompoundFile.FileTable.FileTableEntry)">
            <summary>
            Adds a new file table entry
            </summary>
            <param name="iID"> </param>
            <param name="fent"> </param>
        </member>
        <member name="P:dotnetpcf.CompoundFile.FileTable.EntryCount">
            <summary>
            Number of file table entrys
            </summary>
        </member>
    </members>
</doc>
